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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 
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1 Scope 



The present document contains requirements for a protocol at reference point N of the TIPHON reference configuration 
(see [1]). Reference point N designates the information flows required for control of a Media Gateway in a functionally 
decomposed Gateway. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[1] TS 101313 (V0.4): "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON); Network architecture and reference configurations; Phase II: Scenario 1 + Scenario 2". 

[2] ITU-T Recommendation H.323 (1998): "Packet based multimedia communications systems". 

[3] ITU-T Recommendation H.245 (1998): "Control protocol for multimedia communication". 

[4] ITU-T Recommendation Q.700: "Introduction to CCITT Signalling System No. 7". 

[5] IETF RFC 791 (September 1981): "Internet Protocol, Darpa Internet Program Protocol 

Specification", J. Postel. 

[6] IETF RFC 2460 (December 1998): "Internet Protocol, Version 6 (IPv6) Specification", S. Deering, 

R. Hinden. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Gateway: Endpoint on a network which provides for real-time, two-way communication between terminals on an IP 
based network and other terminals on switched circuit network. 

Media Gateway: Device operating on media streams. 

Media Gateway Controller: Sits between the Media Gateway, the Signalling Gateway and the Gatekeeper. The Media 
Gateway Controller provides the call processing (call handling) function for the Gateway. 

Signalling Gateway: Provides the signalling mediation function between the IP domain and the SCN domain. 
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3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ATM Asynchronous Transfer Mode 

BRI Basic Rate Interface 

DTMF Dual Tone Multi Frequency 

IP Internet Protocol 

NNI Network to Network Interface 

PRI Primary Rate Interface 

QoS Quality of Service 

RTCP Real-time Transport Control Protocol 

RTP Real-time Transport Protocol 

SCN Switched Circuit Networks 

SS7 SignalUng System N°7 

UNI User to Network Interface 



Introduction 



In the reference configuration defined inTS 101 313 [1] reference point N designates the information flows required for 
control of a Media Gateway in a functionally decomposed Gateway. 

Information flows at reference point N need to support for the following functions: 

1) creation, modification, and deletion of media stream connections across the Media Gateway; 

2) specification of the transformations to be applied to media streams as they pass through the Media Gateway, 
when connections are created and subsequently during the life of the connection; 

3) requesting the insertion of tones and announcements into media streams, either by explicit request of the 
Media Gateway Controller or by indicating that insertion should begin and end with the detection of specified 
events within the Media Gateway itself; 

4) requesting the reporting of, and possibly specifying the actions to take upon detection of specified events 
within the media streams. 

4.1 Examples of IVIedia Gateways 

Examples of Media Gateways include but are not limited to the following applications: 



• 



Trunk gateways that interface between SCN networks and IP networks. Such gateways typically interface to 
SS7 or other NNI signalling on the SCN and manage a large number of digital circuits. 



• Voice over ATM gateways which operate much the same way as trunk gateways, except that they interface to an 
ATM network. 

• Access gateways that interface UNI interfaces like ISDN (PRI and BRI) and traditional analogue interfaces to a 
Voice over IP network. 

• Residential gateways are access gateways for a small number of voice terminals that can be co-located with a 
cable modem or set top box. 

• Network Access Servers, which convert modem signals from an SCN network and provide data access to the 
packet network. 



• 



Multipoint Processing Units that provide multipoint connectivity between terminals on SCN and packet 
networks. 



• Interactive Voice Response systems that provide automatic voice response and switching services in response 
to DTMF signals from the SCN. 
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IP Gateways that are used to interface either between administrative domains which apply different policies (e.g. 
proxies), or to transform media streams formats (e.g. transcoding). 

Fax Gateways that are used to relay Fax Group 3 calls between an IP network and an SCN. 



5.1 



Protocol Requirements 



Connection Control 



In keeping with the capabilities of ITU-T Recommendation H.245 [3], connection control shall be able to provide at 
least the following types of connection: 

• circuit to packet (IP); 

• circuit to packet (ATM - ITU-T Recommendation H.323 [2], Annex C operation); 

• packet to packet; 

• circuit-to-circuit (e.g. circuit side fallback). 

The connection mode may be unicast or multicast, or a connection may be inactive. Connections can be specified 
unidirectionally, but may be specified in both directions at once. 

On the IP side, the protocol at reference point N shall permit use of IPv4 [5]. In addition, the protocol at reference point 
N may permit use of IPv6 [6]. 

On the circuit side, the protocol at reference point N shall support the invocation of continuity testing. 

It shall be possible to use the following types of loopback for test purposes: 

• through a circuit at the edge of the Media Gateway (path 1 in Figure 1); 

• through a circuit via the packet side of the Media Gateway (path 2 in Figure 1); 

• through the packet side of the Media Gateway (path 3 in Figure 1); 

• through the packet side via a circuit of the Media Gateway (path 4 in Figure 1). 
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Figure 1 : Possible Types Of Loopbacit 

Abstracting from this, the Media Gateway control interface shall support the following capabilities for connection 
control: 

1) The ability to identify the IP, ATM, and/or circuit local end-points, and local connections within the Media 
Gateway between two or more of its endpoints. The protocol shall permit the designation of endpoints using a 
hierarchical naming construct. 

2) The ability to request that the media gateway selects any one eligible member of a named group. The protocol 
shall enable the media gateway to return the full identity of the selected instance. 
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3) The ability to refer to a specified set of entities. The protocol should include the capability to specify a range 
of entities by naming the initial and final members of this range. 

4) The ability to request the selection of ports for both RTP and RTCP reception on the packet side. The 
numerical values of RTP and RTCP ports may be non-consecutive numbers [2]. 

5) The ability to convey the requested QoS parameters applicable on the packet side of a media stream 
connection. 

6) The abiUty to convey the requested bearer capabilities applicable on the SCN side of a media stream 
connection. 

7) The ability to convey QoS statistics for an established connection at any time during the call and at teardown. 

8) The ability for the Media Gateway to autonomously report if the QoS on a given connection has fallen below 
a specified value. 

5.2 Endpoint Attributes 

The protocol shall be able to convey the following endpoint attributes: 

1) The media protocol used (RTP, fax-protocol, ...). 

2) The payload type (e.g. codec). 

3) The codec -related attributes like packetization interval, jitter buffer size and silence suppression where 
appropriate. 

4) The generation of comfort noise during silent periods. 

5) The application of encryption/decryption and identification of the encryption schemes. 

6) The echo cancellation. 

7) The lawful interception of the content of a specified media stream. 
The protocol shall allow: 

• the specification of the endpoint attributes when the connection is created; 

• modification of endpoint attribute values for an already-existing connection (e.g. in response to a H.245 
FlowControlCommand or ReplacementFor OLC). 

It shall be possible to extend the protocol to support additional endpoint attributes as they are defined without modifying 
the existing semantics. 

5.3 Content Insertion 

The protocol shall support: 

• the ability to request the sending of a specified tone or announcement, at any time, in a specified direction; 

• the specification of the conditions under which the sending should stop; 

• the ability to request muting of a media stream; 

• the ability for the controller to request the Media Gateway to insert and detect tones as required for SS7 [4] 
continuity testing and other forms of testing. 
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5.4 Event Detection and Notification 

The protocol shall support the ability to instruct the Media Gateway to detect, notify and possibly act upon specified 
events. 

Examples of events are: 

• a DTMF tone; 

• off-hook, on-hook. 



5.5 Other Requirements 



As a general requirement, the protocol shall allow the Media Gateway to indicate to the Media Gateway Controller 
whenever some or all of a request cannot be executed. It shall be possible for the Media Gateway to indicate the general 
nature of the problem and to provide further details, possibly including vendor-specific content. 



5.5.1 IVIodularity and Extensibility 



It is essential that the protocol be both modular and extensible. The protocol should be designed such that there is a 
basic part that all implementations must support and that it will be optional to support other parts of the protocol. 

The protocol shall provide the means whereby a Media Gateway Controller can determine the capabilities supported by 
a particular Media Gateway. 

The protocol shall support backwards compatibility as new versions are released. 

The protocol shall allow the possibility of vendor-specific extensions. 



5.5.2 Resource IVIanagement 



The protocol shall provide the means for the Media Gateway Controller to determine resource availability within an 
associated Media Gateway. 

NOTE 1 : The means by which resource availability is quantified is for further study. 

The protocol shall allow for unsolicited resource management messages between the Media Gateway and Media 
Gateway Controller. 

It shall be possible for the Media Gateway to indicate to the controller that it lacks sufficient resources to carry out a 
given command. 

It shall be possible for the Media Gateway Controller to audit the commitment of resources to connections, to ensure 
that all commitments are valid. It shall further be possible for the controller to order that specific resource assignments 
be cleared if it finds that they are invalid. 

It shall be possible for the Media Gateway Controller to audit the connection state of connections in Media Gateways 
with which it is associated. 

It shall be possible for the Media Gateway to report changes in operational status of significant resources from in-service 
to out-of-service and vice versa. 

NOTE 2: This is especially required for transmission facilities terminating on the Media Gateway. 

5.5.3 Association Management 

The protocol shall enable the Media Gateway Controller to control a number of Media Gateways. 

The protocol shall provide the means to establish and remove an association between a specific Media Gateway 
Controller and a specific Media Gateway. 
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It shall be possible for either the Media Gateway or the Media Gateway Controller to detect loss of the association. 

It shall be possible for a Media Gateway to establish an association with an alternate Media Gateway Controller if its 
currently associated Media Gateway Controller becomes unavailable. 

NOTE: These requirements are intended to support any of the following arrangements: 

1:N sparing; 

load sharing; 

hot standby. 

5.5.4 Scripting 

The protocol shall provide the means to download scripts to be executed autonomously by the Media Gateway. 



5.6 Security 



The protocol shall allow for mutual authentication at the start of a Media Gateway Controller to Media Gateway 
association , and for preservation of the integrity and confidentiality of control messages once the association has been 
established. 



6 Subjects for further study 

Support for H.323 fast start. 
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